Documentation follow-ups from a security audit of the Noir contracts. No contract logic changes — comments and READMEs only.

1. token/main.nr — remove a comment that contradicts the code

Both ARC-403 hook wrappers documented from as "(zero address for mints)". No mint path calls either hook, so the parenthetical described the spec's parameter semantics rather than this contract's behaviour.

It was load-bearing in the wrong direction: it was the strongest single reason two independent reviews classified the deliberate design as an authorization bypass (CWE-862). Replaced with a pointer to the README.

2. token/README — state what unhooked mints imply

The README already documented that mints are unhooked and why. Added the consequence for integrators: an authorization contract is not a universal kill switch. Pausing it stops transfers and burns while the minter can still issue supply — so a compromised minter key cannot be contained by the hook, minter being a single immutable address where the hook can encode multisig/timelock/pause.

Also records the open ARC-403 question: hooking mints (with from = zero) would enable pause and supply-cap policies but still not recipient screening, since to is deliberately not forwarded. That's a spec decision for the forum draft, not a patch — flagging it here rather than changing behaviour unilaterally.

3. multitoken/README — new "Commitment trust model" section

initialize_transfer_commitment binds the recipient, randomness and completer, but deliberately not token_id or amount — the completer supplies both at completion. That is documented intent and is genuinely useful when the value depends on public state.

The gap was that nothing said which patterns it is unsafe for. A commitment is not a payment guarantee: a malicious completer can satisfy it with a negligible amount of an arbitrary id, including one they created. Safe when the completer is already trusted for the value; unsafe for escrow, marketplace and handoff flows. Noted that this is a wider surface than Token, where the token is implicit and only the amount is completer-chosen.

Same kill-switch caveat as (2) added, since MultiToken carries the identical mints-unhooked design.

4. vault/README + root README — disclose the reentrancy exposure

The existing warning disclosed the conversion overflow and the privacy limitations, but not the reentrancy exposure, which understated the risk profile.

The vault's protection against reentrancy is the order of its operations (assets in before shares minted, shares burned before assets paid out), which assumes a token transfer is indivisible. It isn't: when the asset token has an ARC-403 auth_contract, that contract runs during the transfer, before balances move, and can observe the vault in exactly the intermediate state the ordering exists to exclude. Reading the share price there yields a value no completed operation produces.

The warning now advises wrapping only assets whose get_auth_contract() is zero, or one whose authorization contract is fully trusted. Vaults over unhooked tokens are unaffected.

Validation

aztec-nargo fmt --check clean · aztec compile OK. No test changes (nothing behavioural changed).

Note

The .nr formatting fix for main's failing Format check lives in #23 and is deliberately not duplicated here.

🤖 Generated with Claude Code